An attribute-based AC (ABAC) policy defines access control permissions based on the attributes of the subject, of the resource, and of the action that the subject is to perform on the resource (e.g., read, write). When the policy is enforced in a computer system or computer network, it controls access to entities in the system or network and thereby influences their state of operation. A resource may be, inter alia, a portion of a personal storage quota, a business unit storage quota, an information retrieval system, a (portion of a) database, an online service, a protected webpage or a physical device.
There currently exist general-purpose AC languages that have the richness to express fine-grained conditions and conditions which depend on external data. One particular example of an AC language is the eXtensible Access Control Markup Language (XACML) which is the subject of standardization work in a Technical Committee within the Organization for the Advancement of Structured Information Standards (see www.oasis-open.org). A policy encoded with XACML consists of functional expressions in attribute values, and the return value (decision) of the policy is one of Permit, Deny, Not Applicable, or Indeterminate. An XACML policy can apply to many different situations, that is, different subjects, resources, actions and environments and may give different results for different combinations of these. The XACML specification defines how a policy is evaluated for a request (or access request), particularly what policy attributes are to be evaluated or, at least, which values are required to exist for a successful evaluation to result. Key characteristics of this evaluation process are that the access request (the query against the policy) must describe the attempted access to a protected resource fully. In practice, it may be that the request is constructed in multiple stages by different components, so that a PEP (Policy Enforcement Point) provides only some initial attribute values and a PDP (Policy Decision Point) or other components can dynamically fetch more attribute values from remote sources as they are needed. For consistency reasons, the attribute values must not be retrieved earlier than the request is made. Rules in an ABAC policy may be nested in a conditional fashion, so that attribute values—both those provided initially in the access request and those fetched from remote sources—will influence what further rules are to be applied. Based on a policy or policy set (unless otherwise indicated, these terms are used interchangeably herein) that covers a broad range of resources and subjects and a given request, it is often possible to obtain a decision by evaluating only a fraction of all functional expressions in the policy. Conversely, it cannot always be ascertained prima facie whether a request contains enough attribute values to allow a successful policy evaluation.
To illustrate, a simple enterprise policy governs use of company printers and company documents (resources). For printers, the printer location is a remote attribute available in a directory. For documents, document classification, type, stage and author are remote attributes available in a database. For users (subjects), their clearance, office location, and nationality are remote attributes available in a directory. The policy (cf. FIG. 2) grants a user access to printers if his or her office is in the same location as the printer. For documents, access is allowed if the user has the same or higher clearance as the document classification, except for document on the “draft” stage, which may be accessed by the author only. Furthermore, if the document type is “military”, then only users of domestic nationality may see the document. When the PDP receives a request about a document, there is no point in looking up attributes about the printer, and conversely, if the request is about a printer, then attributes relating to the document or the user can be ignored.
For this and similar reasons, even if a large portion of the attributes are to be fetched from a remote source with a long response time, a strategy where all attributes appearing in the policy are evaluated initially is generally less efficient than a leftmost-outermost strategy where the attributes are evaluated only when needed, by a series of lookup calls. Neither of these strategies scales well with the policy size or its degree of nesting.